Process for distributing an object-oriented program over a plurality of operating system processes of a computer system

ABSTRACT

In an object-oriented application, a preparation process is used when compiling the sources of the application, a configuration process is used when link-editing, and a communication process is used during execution to call up methods for objects. No adaptation of sources is necessary when a system configuration is changed. This also applied to an extension of the object-oriented application.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to a process for adapting an object-orientedapplication so that the latter can be distributed over a plurality ofoperating system processes.

2. Description of the Related Art

Object-oriented applications can be realized by means of object-orientedprogramming. An object-oriented system comprises not only functions orprocedures which call each other up, for instance in the case ofprogramming with the programming languages Fortran, Pascal and C, butobjects are also provided which communicate with one another byexchanging messages. An example of an object-oriented programminglanguage is the programming language C++ which was developed byextending the wide-spread programming language C. Classes of objects aredeclared by means of type definitions in the programming language C++.The objects are assumed to be variables of a class type and are referredto as instances of the class. Each object has instance variables as aset of data. It is only possible to access the instance variables bymeans of specific functions defined in the respective class definition.These access functions assigned to the class are termed methods of theclass. In the programming language C++, the sending of a message to anobject is equivalent to calling up a method for this object. Theprogramming language C++ supports the inheritance of classes. Theinstance variables and the methods of a class can be assumed by aderived class by means of inheritance. Methods of the base class can bedeclared with the keyword virtual so that these methods can be redefinedin a derived class. Objects can be referenced by pointers, and can alsobe generated dynamically, so that it is only possible to decide atruntime which implementation of a method will actually be executed. Inthe programming language C++ applications are limited to exactly oneprocess within the meaning of the operating system. In a realapplication problems can arise if the application exceeds a certain sizesince operating system processes can only have a limited size. The sizeof a C++ application is therefore also limited without additionalmeasures. Some application areas, in particular automation engineeringand telecommunications, have requirements which necessitate theapplication being distributed over a plurality of independent,separately executable and loadable operating system processes. Such adistribution over a plurality of operating system processes, that is tosay no lightweight processes, cannot be formulated with the languagefacilities of C++ alone. Such a distribution of an application over aplurality of operating system processes requires a considerableextension of the functionality, in that mechanisms of the operatingsystem which establish the communication between the operating systemprocesses are to be used. It is conceivable for the programmerexplicitly to insert calls in the application for inter-processcommunication (IPC), and also for separate IPC classes to be used. Inthis case, the software producer must program the IPC mechanismshimself. The distribution of the application over the individualoperating system processes is permanently encoded in the source program.If it becomes necessary to change the process distribution, theprogrammer must modify the source programs and compile them again.

A communication process is known from the publication "ImplementingRemote procedure Calls" by A.D. Birrel et al in the "ACM Transactions onComputer Systems, Vol. 2, February 1984, New York, USA, pages 39-59",which process enables programs written in a high-level language tocommunicate within a network. This is accomplished here by implementingremote procedure calls (RPC) that make use of a stub concept.

Five software parts are involved in a remote call here: The user, theuser stub, the RPC communication packet, the server stub and the server.The user, the user stub and part of the communication packet is executedon the calling machine; the server, the server stub and another part ofthe communication packet are executed on the called machine. If the userwishes to perform a remote call, then this is done in the same way as anormal call, except that in this case it calls up a correspondingprocedure in the user stub. This user stub is responsible fordetermining a target procedure for the call and packing the arguments inone or more packets, and sending the latter securely to the calledmachine. The information is then unpacked by the server stub at thiscalled machine and said stub calls up a corresponding procedure in theserver in a perfectly normal call. Once this call has been processed inthe server, the server stub returns the results to the suspended processin the calling machine. The results are unpacked there and the user stubreturns them to the user. The communication packet is responsible herefor the return transmission, the confirmations, the packet routing andthe encryption.

A communication process is presented in this publication which relievesthe programmer of the workload of programming detailedcommunication-specific software code. However, compiling andlink-editing the code is still required after specifying the systemenvironment. The problem of distributing objects of an object-orientedapplication in conjunction with a variable system environment is notaddressed therein.

SUMMARY OF THE INVENTION

The object of the invention is to state a process for adapting anobject-oriented application which can be distributed over a plurality ofoperating system processes, in particular so that the programmer doesnot need to modify the sources of the application to be compiledhimself.

This object is achieved in a process for adapting an object-orientedapplication which can be distributed over a plurality of operatingsystem processes

a) with a preparation process for code substitution of sources of theapplication to be compiled in accordance with a stub concept,

b) with a configuration process for distributing instances of theapplication as objects or stub objects for modules to be linked fromcompiled sources of the application,

c) with a communication process provided during execution for calling upmethods for objects of the application with the aid of a stub method.

A preferred process with at least one of the following process steps ofthe preparation process can be executed:

d) a class declaration of the sources is analyzed for allocating methodidentifications so that methods of used classes of the application canbe clearly identified by means of the method identification,

e) the classes of the application are extended with a generic method, bymeans of which the particular method identified by a parameter of thegeneric method in the form of the method identification can be called uplocally during execution,

f) base classes of the application are extended by a redefinablydeclared stub method,

g) each of the calls of a method for an object of the classes providedduring execution is replaced by a call of the stub method for the objectprovided during execution,

so that in the case of a positive result of the call of the stub methodfor the object during execution, a call is provided for trans-processsending of a message, by means of which the call of the method of theobject is initiated in a remote process, in that the message containsthe method identification,

and also that the method of the object is called up in the case of anegative result of the call of the stub method for the object duringexecution in the local process,

h) auxiliary definitions for methods are generated so that there aredefined for each method of the application at least

its class name,

its method name,

its parameter types,

its parameter string for packing and unpacking parameters, and also

its method identification.

A further preferred process with at least one of the following processsteps of the configuration process can be executed:

k) a particular system configuration of the application is analyzed fordistributing the objects as the instances of the application over theoperating system processes of the application,

m) a generic instantiation function is generated by means of which a newobject of the application can be instantiated during execution,

with a local instantiation in the local process in the case of an objectto be instantiated locally in accordance with the system configuration,so that the negative result is provided for said locally instantiatedobject when the stub method is called up in the local process,

and also with a remote instantiation in the case of an object to beinstantiated remotely in accordance with the system configuration, inthat a trans-process trigger is provided in the local process forinstantiating said object to be instantiated remotely in the remoteprocess, and also with a local instantiation for a local stub objectprovided for this object, the stub method of which is redefined in thelocal process, so that when the stub method is called up the positiveresult is provided in the local process for this object locallyinstantiated as stub object,

n) a generic delete function is generated, by means of which theinstantiation can be deleted by one of the objects of the applicationduring execution,

with a local deletion in the local process for a locally instantiatedobject in accordance with the system configuration,

and also with a remote deletion for a remotely instantiated object inaccordance with the system configuration, in that a trans-processtrigger is provided in the local process for deleting said remotelyinstantiated object in the remote process, as well as a local deletionof the local stub object provided for said object,

p) runfiles are generated, in that modules

for the instantiation function,

for the delete function, and also

for the auxiliary definitions for the methods of the application arelinked to the modules for each loadable unit.

A further preferred process with at least one of the following processsteps of the communication process can be executed:

r) the stub method for one of the objects is called up locally, and alsoa local method call for the object is made in the case of a negativeresult,

s) in the case of a positive result for the local call of the stubmethod for the object

the method identification,

the remotely instantiated object, and also

method parameters are determined from the linked auxiliary definitions,

t) a message is packed in the local process on the basis of theparameter string,

u) the message is received in the remote process,

v) the locally instantiated object is determined in the remote processafter unpacking the parameters,

w) the call of the method thereby identified is executed by means of thegeneric method on the basis of the method identification.

The invention is based on the idea that the sources of the applicationto be compiled can be modified in a preparation process, preferably bymeans of a preprocessor, so that by means of code substitution methodcalls can be replaced by code sequences, by means of which it ispossible to decide during execution whether trans-process sending of amessage is required, or whether a local call is to be made. This can berealized in that auxiliary definitions are generated for the methods, sothat protection of the consistency of the system for the application isensured by using these special files. This can be further achieved inthat a stub concept is applied in which stub methods and stub objectsare used. This can furthermore be achieved in that an instantiationfunction and also a delete function are inserted into a runtime system.This can furthermore be achieved in that in particular a generic methodis used for a trans-process communication process during execution, bymeans of which the method call identified thereby can be executed on thebasis of a method identification.

Advantageously, the programmer need not modify the sources himself.

The programmer can advantageously create the sources of the applicationusing the language facilities of the programming language C++ forexample.

In an advantageous manner, modification of the sources together withtheir subsequent compilation only once is sufficient during thepreparation process as a result of the code substitution. If the systemconfiguration changes, that is to say if the distribution of theapplication over a plurality of operating system processes changes, itis not necessary to change the sources of the application, so that newcompilation is not required either.

In an advantageous manner, the consistency of the overall system of theobject-oriented application is ensured for a particular systemconfiguration by means of the auxiliary definitions.

The invention will be explained in greater detail with reference to thefigures which contain exemplary embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a process according to the invention for adapting anobject-oriented application which can be distributed over a plurality ofoperating system processes.

FIG. 2 show another process for adapting an object-oriented applicationwhich can be distributed over a plurality of opting system processes.

FIG. 3 shows a preparation process for the process according to theinvention for adapting an object-oriented application which can bedistributed over a plurality of operating system processes.

FIG. 4 shows a configuration process for the process according to theinvention for adapting an object-oriented application which can bedistributed over a plurality of operating system processes.

FIG. 5 shows a trans-process communication process for the processaccording to the invention for adapting an object-oriented applicationwhich can be distributed over a plurality of operating system processes.

FIG. 6 shows a method call.

FIG. 7 shows a code sequence after code substitution of the method call.

FIG. 8 shows a trans-process send call for a message as part of the codesequence.

FIG. 9 shows a call of a stub method as a part of the code sequence.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

As FIG. 1 shows, an exemplary embodiment of the process according to theinvention for adapting an object-oriented application which can bedistributed over a plurality of operating system processes comprises theprocess steps V100, V200, V300, V400, V500, V600 and V700.

process step V100 is executed. The sources of the application to becompiled are created by the programmer.

process step V200 is executed. A preparation process is performed forthe created sources of the application to be compiled. A preprocessorcan be provided here to perform the preparation process. Classdeclarations of the sources of the application are analyzed. Methodidentifications are prepared. The classes of the applications areextended by the generic method. The method calls in the sources of theapplication are modified, in that code sequences are inserted instead ofthe method calls by means of code substitution. Auxiliary definitionsare generated for the methods of the application.

process step V300 is executed. The sources modified by the preparationprocess are compiled.

This is followed by process step V400. A configuration process isexecuted. A configuration file is analyzed. An instantiation function isgenerated. A delete function is generated. Auxiliary definitions for themethods of the application are co-linked. Runfiles are generated.

This is followed by process step V500. A link process is executed.Executable phases of the operating system processes are linked.

This is followed by process step V600. One run of the operating systemprocesses of the application is executed.

This is followed by process step V700. It is examined whether it isnecessary to change the configuration. If this is the case, process stepV400 follows. The configuration process is performed again in accordancewith the changed system configuration. This is followed by process stepV500 in which the link process is performed again. This is followed byprocess step V600 in which the application is executed in accordancewith the changed system configuration.

As FIG. 2 shows, an exemplary embodiment of another process for adaptingan object-oriented application comprises the process steps V101, V301,V501, V601, V701 and V801.

process step V101 is executed. The sources of the application arecreated by a programmer. Depending on the distribution of theapplication over a plurality of operating system processes, theprogrammer explicitly enters the calls for trans-process communicationinto the sources of the application.

This is followed by process step V301. The created by the programmer arecompiled.

This is followed by process step V501. The link process is executed forthe compiled sources of the application.

This is followed by process step V601. The application is executed.

This is followed by process step V701. It is checked whether it isnecessary to change the configuration. If this is the case, process stepV801 follows. The sources of the application are modified by theprogrammer in accordance with a new system configuration, in that callsfor trans-process communication are explicitly inserted into the sourcesin accordance with the new distribution of the application overindividual operating system processes. This is followed by process stepV301 again, in which the sources that have just been modified arecompiled.

This is followed by process step V501 in which the link process isperformed again.

This is followed by process step V601 in which the application isexecuted in accordance with the new system configuration.

As FIG. 3 shows, an exemplary embodiment of the preparation process ofthe process step V200 comprises the process steps V210, V220, V230,V235, V240 and V250.

process step V210 is executed. A class declaration of the sources of theapplication is analyzed for allocating method identifications so thatthe methods of the classes of the application used can be clearlyidentified across the whole system by means of the methodidentification.

This is followed by process step V220. A protocol information file isprepared which contains auxiliary definitions for the methods of theapplication, so that for each method of the application at least itsclass name, its method name, its parameter types, its parameter stringfor packing and unpacking parameters and also its method identificationare defined.

This is followed by process step V230. The classes of the applicationare extended by the generic method. On the basis of the methodidentification it is possible to execute a call of the method identifiedthereby by means of the generic method.

This is followed by process step V235. The base classes of theapplication are extended by a redefinably declared stub method.

This is followed by process step V240. The method calls in the sourcesare modified by means of code substitution.

This is followed by process step V250. The auxiliary definitions for themethods are generated and prepared in an auxiliary definition file.

As FIG. 4 shows, an exemplary embodiment of the configuration process ofthe process step V400 comprises the process steps V410, V420, V430, V440and V450.

process step V410 is executed. A particular system configuration of theapplication is analyzed on the basis of a configuration file, by meansof which a distribution of the objects of the application over theoperating system processes of the application is performed.

This is followed by process step V420. A generic instantiation functionis generated, by means of which the objects of the application can beinstantiated during execution.

This is followed by process step V430. A generic delete function isgenerated, by means of which the instantiation of the objects of theapplication can be deleted during execution.

This is followed by process step V440. Modules for the auxiliarydefinitions for the methods of the application are linked.

This is followed by process step V450. Runfiles are generated, in thatmodules for the instantiation function, for the delete function and alsofor the auxiliary definitions for the methods of the application arelinked to the modules for each loadable unit.

As FIG. 5 shows, as part of the process step V600, an exemplaryembodiment of a process step V605 comprises the process steps V610 toV680 for a pass for calling up a method for an object of theapplication.

The process step V610 is executed in a local process. A local addresseeis determined. In the case of a local object, the latter is the instanceitself. In the case of a remote object, the local addressee is theassociated stub object.

This is followed by process step V620. The stub method is called up forthe local addressee.

This is followed by process step V621. It is checked whether the resultof calling up the stub method for the local addressee is positive.

If the result is negative, process step V680 follows and the method forthe local addressee is called up, which in this case is the instantiatedlocal object.

process step V640 follows if the result is positive. The methodidentification of the method to be called up is determined.

This is followed by process step V641. The remote addressee isdetermined, which in this case is the remotely instantiated object.

This is followed by process step V642. The parameters for the remotecall of the method are packed.

This is followed by process step V670. Inter-process communication (IPC)takes place between the local process and the remote process.

process step V650 follows in the remote process. The parameters forcalling up the method are unpacked.

This is followed by process step V651. The local addressee in the remoteprocess is determined. In this case this is the object instantiated inthe remote process.

This is followed by process step V652. The generic method in which themethod to be called up is determined by means of the methodidentification is called up.

This is followed by process step V660. The method for the objectinstantiated in the remote process is called up.

The local process is resumed after the remote process by means of theinter-process communication of process step V670.

As FIG. 6 shows, an exemplary embodiment of a local call of a method foran object comprises an object pointer, a method name, and parameters.The object pointer forms here a reference to the object to which amessage is sent. The method name forms here a designation for themessage. The parameters form here a parameter part for the message.

In accordance with accepted notation, the following notation applies forexample:

<objectpointer>→<methodname>(<parameters>)

<objectpointer>: Reference to the object to which the message is sent

<methodname>: Designation of the message

<parameters>: parameter part for the message.

For example, in the programming language C++, its communicationmechanism is designed in such a way that only the addressing of objectswithin one operating system process is supported. Applications that areto be distributed over a plurality of independent operating systemprocesses therefore require an extended communication mechanism. Thisextension of the communication mechanism should not be accomplished byextending the programming language, since this restricts portability.This communication mechanism should be extended in such a way thatportability is ensured. In addition to the local process communicationmechanism anchored in the programming language, a mechanism fortrans-process message exchange should also be made available in the formof inter-process communication (IPC). No new language facilities shouldbe required here, so that no compiler extension is necessary. In apreparation process for the sources of the application to be compiled,such a method call should be replaced by means of code substitution by apreprocessor by a code sequence which contains additional implicit callsfor the trans-process message exchange (IPC). Both the local processmessage exchange and an extended message exchange across processboundaries is to be permitted by means of said code sequence.

As FIG. 7 shows, an exemplary embodiment of such a code sequencecomprises a local call of a stub method Vstub, so that in the case of apositive result for this call, an extended form of the call is providedfor inter-process communication (IPC), and also that in the case of anegative result a local method call is provided which is the same as themethod call illustrated in FIG. 6, which is replaced by the codesequence illustrated in FIG. 7 during the code substitution.

In accordance with accepted notation, the following notation applies forexample:

((<objectpointer>→Vstub())?(SX₋₋ SEND((₋₋ CSXobj*)

<objectpointer>,<methodID>,<parameterstring>,

<parameters>):

<objectpointer>→<methodname>(<parameters>))

<methodID>: Method identification for the system-wide unambiguousidentification of methods of classes of the application

<parameterstring>: Character string for identifying parameters whenpacking and unpacking parameters.

The method identification serves here for the system-wide unambiguousidentification of methods for classes of the application. A parameterstring is provided which serves in the form of a character string toidentify parameters when packing and unpacking parameters.

As FIG. 8 shows, an exemplary embodiment of such an extended form of thecall for inter-process communication (IPC) contains a call fortrans-process sending of the message, an object pointer, a methodidentification, a parameter string and parameters.

In accordance with accepted notation, the following notation applies forexample:

SX₋₋ SEND((₋₋ CSXobj,*)<objectpointer>,<methodID>,<parameterstring>,<parameters>)

Whether this call is actually activated is decided at runtime byevaluating the result determined as an inquiry using the call of thestub method.

As FIG. 9 shows, an exemplary embodiment of a call of the stub methodcomprises an object pointer and also the method name Vstub.

In accordance with accepted notation, the following notation applies forexample:

(<objectpointer>→Vstub())

Before sending the message according to the method name to the objectreferenced, it is determined in each case whether a local process methodcall is to be performed, or whether a call extended by means ofinter-process communication (IPC) is to be performed. In the case of anIPC call, the function SX₋₋ SEND is used, and this must be provided withthe appropriate parameters. This provision of parameters should beperformed automatically by the preprocessor during the codesubstitution.

The code substitution is advantageously carried out according to simplerules so that it can be automated and can be performed by a tool forexample.

Together with the code substitution for the message calls, it is alsonecessary to substitute the parts of code relating to the instantiationof classes and the removal of objects from the system.

The decision as to which form of the communication mechanism is used ineach case, that is to say sending of the message locally in the processor trans-process sending of the message, should be made at programruntime, to be precise depending on a current system constellation,which is dynamically variable in object-oriented software systems. Inorder to ensure high performance, this inquiry should be carried outvery quickly and therefore locally in the process. An instance shouldexist in each case in every operating system process which can provideinformation as to whether an addressed object is currently located inthe respective operating system process of the message sender, or, if itexists in another operating system process, provide route information toenable addressing. This should be handled by means of a stub concept.

In such a stub concept, representative objects should be present as stubobjects instead of the real objects in a distributed application inoperating system processes which do not themselves contain a realobject. Said stub objects are then available locally as a contact pointin the event of a request to the real object and can either directlyassume the tasks thereof or forward the required service to the realobject. Said stub objects should behave towards the other objects inexactly the same way as real objects.

Such a task or possible service is, for example, the information as towhether a particular object is the instance itself or the stub object.If it is the instance itself, the message can be sent directly to theaddressed object in the customary form for the programming language C++for example. Otherwise, the stub object should make available all thenecessary information about it in order to forward the relevant requestto the real object. If each object, including the stub objects, canprovide information as to whether it itself is a stub object or not. Amethod, the stub method Vstub(), is made available as a virtual methodin the base class of all application classes for this purpose. As aresult of the inheritance mechanism, all objects of the applicationautomatically receive the capability of providing information as towhether they are stub objects or real objects. The stub method whichsupplies a negative result in the event of an activation is madeavailable in the base class of all application classes. The stub methodmust be declared in a redefinable manner, in that the stub methodcontains the keyword virtual in the programming language C++ forexample. For stub classes, the stub method is redefined so that itsupplies a positive result. Accordingly, in response to the inquiryVstub(), in accordance with the stub method stub objects supply adifferent result than the non-stub objects, for which a defaultimplementation is used.

A system configuration, that is to say a distribution of the objectsover operating system processes, need only be defined after thetranslation of the source programs. It should only be decided at runtimewhich communication mechanism is used in each case. This also applies tothe procedure of instantiation of classes as well as the removal ofobjects from the running system. This cannot be performed statically bythe compiler, but rather should be executed by the runtime system.

Just as with the code substitution for the message calls, the calls NEWand DELETE are also replaced in the source by the preprocessor by thefunctions SX₋₋ NEWobj as instantiation function and SX₋₋ DELETE asdelete function. These functions are executed in the runtime system.These functions are linked to each loadable unit. They incorporateinformation about whether an object is to be instantiated locally orremotely or is to be deleted. Accordingly, during the instantiationeither the operator NEW is used in the programming language C++ forexample, or the instantiation of the object in another operating systemprocess is initiated via inter-process communication and in this caseonly a stub object is generated locally. The delete function decides atruntime whether the object to which it is applied is a stub object or areal object. Depending on this, either the operator DELETE is used inthe programming language C++ for example, or the deletion of an objectin another operating system process is initiated via inter-processcommunication and the stub object is deleted locally. The implementationof the instantiation function and the delete function is generated onthe basis of specifications in a configuration file.

In the case of the trans-process communication mechanism, method calls,that is to say also calls of constructors and destructors, go beyondprocess boundaries, so that these calls must be converted into data thatcan be sent. The methods of the classes used are identified here bymethod identifications. Said method identifications are allocatedunambiguously across the whole system by means of a protocol informationfile for example and are evaluated by means of the generic method whicheach object possesses. The protocol information file forms a system-widedatabase of methods and their method identifications. This is evaluatedduring each code substitution and supplemented where necessary. Theprotocol information file contains the following data for each method ofthe application:

class name

method name

types of the parameters of the method (this information is necessarysince, in the programming language C++ for example, methods cannot beclearly identified solely on the basis of class names and method names,but only by the parameter types)

parameter string (used for packing and unpacking the parameters forexample)

method identification.

During the code substitution, the definition of each class used isextended by the generic method. The latter maps the methodidentifications onto local method calls. Each method call from anotherprocess initially leads in the receiving process to a call of thegeneric method with the method identification as parameter.

In the case of trans-process sending of the message, the parameters ofthe method call are packed and sent in a data structure. The functionsSX-SEND and the generic method are provided for the packing andunpacking of the parameters. For this, information about methodparameters is transferred encoded to the function SX-SEND, for examplein the form of a string. This information string, that is to say theparameter string, is likewise prepared by the preprocessor during thecode substitution.

In this way in an object-oriented application a preparation process isused when compiling the application, a configuration process is usedwhen link-editing, and a communication process is used during executionto call up methods for objects. No adaptation of sources is necessarywhen a system configuration is changed. This also applies to anextension of the object-oriented application.

Although other modifications and changes may be suggested by thoseskilled in the art, it is the intention of the inventors to embodywithin the patent warranted hereon all changes and modifications asreasonably and properly come within the scope of their contribution tothe art.

We claim:
 1. A computer driven process for distributing anobject-oriented application, which is written in a programming languagewhose communication mechanism is designed in such a way that only theaddressing of objects within one computer-operating system is supported,over operating system processes that can be loaded and executed locallyand remotely, the process comprising the steps of:a) initiating apreparation process in which, for sources of the application to becompiled, at least one method call is replaced by a code sequence by:substitution code by a preprocessor during compilation in accordancewith a stub concept; providing information as to whether an addressedobject is currently located in the respective operating system processof the message sender at an instance that exists in every operatingsystem process, or, if it exists in another every operating systemprocess, providing route information to enable addressing, so thatrepresentative objects are present as stub objects instead of the realobjects in the distributed application in operating system processeswhich do not themselves contain a real object; b) distributing instancesof the application with a configuration process for modules to be linkedfrom compiled sources of the application as objects or stub objects overthe operating system processes in accordance with a system configurationwhen link-editing the modules; and c) calling up methods for objects ofthe application with a communication process provided during executionenabling a decision by using a local call of the stub method as towhether trans-process sending of a message is required or whether thecall can be handled locally.
 2. The computer-driven process of claim 1,with at least one of the following process steps of the preparationprocess:d) analyzing a class declaration of the sources for allocatingmethod identifications so that methods of used classes of theapplication are clearly identifiable by means of the methodidentification; e) extending the classes of the application with ageneric method by means of which the particular method identified by aparameter of the generic method in the form of the method identificationcan be called up locally during execution; f) extending base classes ofthe application by a redefinably declared stub method; g) replacing eachof the calls of a method for an object of the classes provided duringexecution by a call of the stub method for the object provided duringexecution,so that if a positive result of the call of the stub methodfor the object during execution, a call is provided for trans-processsending of a message, by means of which the call of the method of theobject is initiated in a remote process, in that the message containsthe method identification, and also that the method of the object iscalled up if a negative result of the call of the stub method for theobject during execution in the local process; h) generating auxiliarydefinitions for methods so for each method of the application at leastits class name, its method name, its parameter types, its parameterstring for packing and unpacking parameters, and also its methodidentification are defined.
 3. The computer driven process of claim 2with at least one of the following process steps of the configurationprocess:k) analyzing a particular system configuration of theapplication for distributing the objects as the instances of theapplication over the operating system processes of the application; m)generating a generic instantiation function by means of which a newobject of the application can be instantiated during execution,with alocal instantiation in the local process in the case of an object to beinstantiated locally in accordance with the system configuration, sothat the negative result is provided for said locally instantiatedobject when the stub method is called up in the local process, and alsowith a remote instantiation in the case of an object to be instantiatedremotely in accordance with the system configuration, in that atrans-process trigger is provided in the local process for instantiatingsaid object to be instantiated remotely in the remote process, and alsowith a local instantiation for a local stub object provided for thisobject, the stub method of which is redefined in the local process, sothat when the stub method is called up, the positive result is providedin the local process for this object locally instantiated as stubobject; n) generating a generic delete function by means of which theinstantiation can be deleted by one of the objects of the applicationduring execution,with a local deletion in the local process for alocally instantiated object in accordance with the system configuration,and also with a remote deletion for a remotely instantiated object inaccordance with the system configuration, in that a trans-processtrigger is provided in the local process for deleting said remotelyinstantiated object in the remote process, as well as a local deletionof the local stub object provided for said object; and p) generating runfiles in that modules for the instantiation function, for the deletefunction, and also for the auxiliary definitions for the methods of theapplication are linked to the modules for each loadable unit.
 4. Thecomputer driven process of claim 3 with at least one of the followingprocess steps of the communication process:r) calling up the stub methodfor one of the objects locally and also making a local method call forthe object for a negative result; s) determining for a positive resultfor the local call of the stub method for the object the methodidentification, the remotely instantiated object, and also methodparameters from the linked auxiliary definitions; t) packing a messagein the local process based on the parameter string; u) receiving themessage in the remote process, v) determining the locally instantiatedobject in the remote process after unpacking the parameters and w)executing the call of the method thereby identified by means of thegeneric method based on the method identification.